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REMARKS 

Claims 1-16 remain in the Application. No claim has been allowed. 

Claims 1, 5-9, and 1 1-14, and 16 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Kadansky (U.S. 6,507,562) in view of Dillon (U.S. 2003/0206554) and further 
in view of Ronning (US2003/02 12992). Claims 2, 3, and 15 stand rejected under 35 U.S.C. 
103(a) as being unpatentable over Kadansky and Dillon in view of Ronning and further in view 
of Gupta (U.S. 6,577,599). Claim 4 stands rejected under 35 U.S.C. 103(a) as being 
unpatentable over Kadansky and Dillon in view of Ronning and further in view of McNeil (U.S. 
6,421,706). Claim 10 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kadansky, Ronning and Dillon in view of McNeil and further in view of Wada (U.S. 
2003/0007481). 

Claim 1 of the present invention, as currently amended, claims a method for content push 
synchronization for bulk data transfer in a multimedia network. The method includes, in part, 
scheduling transmission of bulk data content and notifying a plurality of end node devices of the 
scheduled bulk data transmission. The notification includes sending information over the 
network indicating an expected end time for the scheduled transmission. This notification occurs 
before the bulk data transmission begins . 

Ronning describes an agent software application for controlling distribution of files and 
managing updates to files (Abstract). " While the file is being downloaded, the agent displays 
and continually updates download status screen" (para. [0090]). Such a download status screen 
is a realtime indicator that provides information after the download begins and is regularly 
updated while the download is taking place to reflect the current file's download status. That is, 
because the status screen indicator represents a file's download status, the 'notification' is 
provided after the download begins and while it continues, but not before, as recited in 
Applicants' claims. 

Furthermore, Fig. 7 of Ronning also clearly indicates that the status screen 'notification' 
occurs well after the download process begins, not before. For example, referring to Fig. 7, after 
the download begins, a "Server transmits a file list to the agent" 606, a "User selects file to 
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download" 608, the "Server downloads the file to agent" 612, the "Agent receives file" 614, and 
- several steps after the download begins - the "Agent displays and continually updates 
download status screen" 616. 

The Office Action states that Ronning discloses "a notification (status screen/indicator to 
indicate download time) that occurs before bulk data transmission (the status indicator is at zero 
prior to the start of downloading the data and moves from left to right as the data is received 
filling up section 792 in Fig. 21 A until the file is completely downloaded — paragraph 0090, lines 
1-20)" (Page 6, 2 nd para.). However, after a careful review of the cited passages, Applicants' 
submit that Ronning does not teach a status indicator being created " prior to the start of 
downloading." As illustrated in Fig. 7, the status indicator is created only after download begins. 

Applicants are essentially sending a message in advance of the transfer to end nodes, 
whereas Ronning is monitoring the status of the transfer's completion at the end node. 
Therefore, Applicants' respectively submit that Ronning's status screen (i.e., notification) 
provides a visual display after the download begins (i.e., transmission). Ronning's status screen 
is not a "notification occurring before the bulk data transmission begins " as claimed in currently 
amended base Claim 1 . 

The Office Action also appears to argue that the status screen of Ronning is an "indicator 
to indicate download time " because "the status indicator is at zero prior to the start of 
downloading the data and moves from left to right as the data is received filling up section 792 in 
figure 21 A until the file is completely downloaded." (Page 6, 2 nd para.) 

However, paragraph [0090] indicates that the download status screen provides "an 
expanding status bar displaying essentially in realtime a relative indication of the amount that the 
file is downloaded (i.e. bytes). The status bar moves, for example, from left to right filling up 
section 792 until the file is completely downloaded." In addition, the statement "the status 
indicator is at zero" must refer to bytes - not time - since the only place Ronning refers to "zero" 
is with respect to bytes in paragraph [0086]: "If this was the first time the file is requested to be 
downloaded, the start byte will be zero." Furthermore, the statement regarding the indicator 
moving "left to right as the data is received filling up section 792 in figure 21 A until the file is 
completely downloaded" also indicates bytes, not time. Thus, Ronning's increasing display bar 
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merely represents an increasing number of bytes downloaded, not an indicator of the time at 
which the download begins , as recited in the claims. 

Assuming the Office Action was instead referring to the "Est. remaining time to 
completion" field in Fig 21 A, Applicants' kindly submit that this field is merely a countdown 
timer that represents a constantly varying number of seconds triggered by an event that occurred 
in the past (begin download) and is relative to a non-absolute event (download status) - an event 
that may never occur (e.g., download is cancelled). It is not a fixed, absolute "end time" 
representing a future time that is certain occur. Additionally, the Applicants, acting as their own 
lexicographer, have defined "end time" to be expressed in Universal Time Code (UTC) which is 
known in the art of multicast transmission as a particular date and time. Furthermore, Ronning's 
countdown timer would not work with the claimed method since Applicants' promotions have an 
absolute expiration time and a varying countdown timer based on download status would not be 
able to recognize such an expiration. 

With respect to item 3 of the Office Action at hand, Applicants' maintain that Kadansky 
does not teach notifying end node devices of an expected start time and duration information, as 
argued in the previous amendment, and as further argued below. 

The Office Action states that Kadansky "discloses a method wherein the step of notifying 
the end node devices includes an expected start time and duration information wherein Kadansky 
disclosed that the sending starts 1.5 seconds from the beginning of the simulation, which reads 
on an expected start time." 

To the contrary, Kadansky cannot notify end node devices of an expected start time 
because Kadansky discloses a simulation , thus there are no "end node devices" to notify. One 
skilled in the art would clearly recognize that a simulation is, by its very nature, a purely 
software exercise - there are no "end node devices to notify." Running a software simulation is 
very different than sending time information to real, physical end node devices. Furthermore, 
Kadansky does not teach or suggest notifying end nodes of any time information whatsoever, 
much less its availability in the first place. As disclosed in Kadansky, the simulation and the 
'live' operation are two distinct, unrelated modes of operation that do not interact. 
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However, in the interest of expediting prosecution, claim 1 has been further amended to 
clarify that the information is sent over a network as opposed to Kadansy's local simulation. 
Therefore, Applicants' claimed feature of "notifying a plurality of end node devices of the 
scheduled bulk data transmission, such notification including sending information over the 
network indicating an expected end time for the scheduled transmission, the notification 
occurring before the bulk data transmission begins is not found in Kadansky or the newly cited 
Ronning reference. 

Dillon does not provide the missing claimed feature of Applicants' invention. In order for 
an invention to be considered obvious, each element of the claim must be found in the prior art. 
Therefore, Claim 1, as currently amended, is not obvious or anticipated by Kadansky, Ronning, 
or Dillon and should be allowable. 

Claims 2, 3 and 15 were also rejected as being unpatentable over Kadansky and Dillon in 
view of Ronning and further in view of Gupta. As has been explained above, neither Kadansky, 
Dillon, nor Ronning teach the claimed step of notifying a plurality of end node devices of the 
scheduled bulk data transmission, such notification including information indicating an expected 
end time for the scheduled transmission, the notification occurring before the bulk data 
transmission, and, thus, cannot be considered to provide all of Applicants' claimed features. 
Neither does Gupta. These claims should be allowable. 

Claim 4 was further rejected in view of Kadansky and Dillon in view of Ronning and 
further in view of McNeil. McNeil also does not supply the novel elements of Applicants' claim. 
In particular, McNeil has no teaching of notifying a plurality of end node devices of a scheduled 
bulk data transmission including information that can be used to determine an expected end time. 
Thus, claim 4 should be likewise allowable. 
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CONCLUSION 



In view of the above amendments and remarks, it is believed that all claims are in 
condition for allowance, and it is respectfully requested that the application be passed to issue. If 
the Examiner feels that a telephone conference would expedite prosecution of this case, the 
Examiner is invited to call the undersigned. 



Respectfully submitted, 



HAMILTON, BROQ 



TH & REYNOLDS, P.C. 




David J. ThroodeaurJr. 
Registration No. 31,671 
Telephone: (978) 341-0036 
Facsimile: (978)341-0136 



Concord, MA 01742-9133 
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